When new software products are introduced to market, it is often the case that they will bear dependencies on other software components or products. The number and nature of such dependencies over the full range of products is certainly vast and complex, and currently there is no centralized or universal source of data regarding such dependencies.
Clearly, numerous problems can result from this. For instance, multiple copies of the same software product can be distributed, resulting in software “bloat”. If “Product A” depends on products “B” and “C”, while “C” depends on “B”, then this can needlessly result in two copies of “B” being distributed with each “A”. Or, one may consider a common product such as the Java “Run Time Environment”. Inasmuch as a number of software programs can well rely on this, a number of different products may well have a copy of the Java “Run Time Environment” on a disk for distributing each product. Accordingly, if three different and independent programs are installed on a machine, the same machine can end up having three copies of the Java “Run Time Environment”.
Further, it can be appreciated that different products may well employ different versions of products with which a dependency exists, meaning that an inefficient degree of hypervigilance needs to be applied when releasing a product (e.g., in the above example, at a given point in time, “A” might depend on one version of “B” while “C” might depend on another version of “B”).
An undesirable result of the above-described conventional scenarios can be the distribution and installation of multiple copies of a product at a machine, leading to increased disk space usage and maintenance problems.
Two conventional approaches have sought to mitigate such problems. In a first approach, each product bears or creates a unique signature to identify itself and registers with a common inventory database when it is installed. However, this requires changes to be made to the product, which may well not be suitable in the case of legacy products and acquired products. In another approach, a unique file or registry signature is created manually for each product. A prime disadvantage here is that the approach is not scalable for potentially thousands of products to which it may be applied. Also, as the signature is identified without the consent of a product team, manual effort typically must be expended to identify the signatures for each new release.